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Mapping and Interworking of Diversion Information between Diversion and 
History-Info Headers in the Session Initiation Protocol (SIP) 


Abstract 


Although the SIP History-Info header is the solution adopted in IETF, 
the non-standard Diversion header is nevertheless widely implemented 
and used for conveying call-diversion-related information in SIP 
signaling. 


This document describes a recommended interworking guideline between 
the Diversion header and the History-Info header to handle call 
diversion information. In addition, an interworking policy is 
proposed to manage the headers’ coexistence. The History-Info header 
is described in RFC 4244 and the non-standard Diversion header is 
described, as Historic, in RFC 5806. 


Since the Diversion header is used in many existing network 
implementations for the transport of call diversion information, its 
interworking with the SIP History-Info standardized solution is 
needed. This work is intended to enable the migration from non- 
standard implementations and deployment toward IETF specification- 
based implementations and deployment. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6044. 
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1. Introduction 
1.1. Overview 


For some VoIP-based (Voice over IP) services (e.g., voicemail, 
Interactive Voice Recognition (IVR) or automatic call distribution), 
it is helpful for the called SIP user agent to identify from whom and 
why the session was diverted. For this information to be used by 
various service providers or by applications, it needs to pass 
through the network. This is possible with two different SIP 
headers: the History-Info header defined in [RFC4244] and the 
historic Diversion header defined in [RFC5806], which are both able 
to transport diversion information in SIP signaling. 


Although the Diversion header is not standardized, it is widely used. 
Therefore, it is useful to have guidelines to make this header 
interwork with the standard History-Info header. 


Note that the new implementation and deployment of the Diversion 
header is strongly discouraged. 


This document provides a mechanism for header-content translation 
between the Diversion header and the History-Info header. 


1.2. Background 


The History-Info header [RFC4244] and its extension for forming SIP 
service URIs (including Voicemail URI) [RFC4458] are recommended by 
the IETF to convey redirection information. They are also 
recommended in the "Communication Diversion (CDIV) service" Third 
Generation Partnership Project (3GPP) specification [TS_24.604]. 


Originally, the Diversion header was described in a document that was 
submitted to the SIP Working Group. It has been published now as 
[RFC5806] for the historical record and to provide a reference for 
this RFC. 


This header contains a list of diverting URIs and associated 
information providing specific information as the reason for the call 
diversion. Most existing SIP-based implementations have implemented 
the Diversion header when no standard solution was ready to deploy. 
The IETF has finally standardized the History-Info header, partly 
because it can transport general history information. This allows 
the receiving part to determine how and why the session is received. 
As the History-Info header may contain further information than call 
diversion information, it is critical to avoid losing information and 
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be able to extract the relevant data using the retargeting cause URI 
parameter described in [RFC4458] for the transport of the diversion 
reason. 


The Diversion header and the History-Info header have different 
syntaxes, described below. Note that the main difference is that the 
History-Info header is a chronological writing header whereas the 
Diversion header applies a reverse chronology (i.e., the first 
diversion entry read corresponds to the last diverting user). 


Appendix A provides an interworking guideline between the Diversion 
header and the Voicemail URI, which is another way to convey 
diversion information. The Voicemail URI is defined in [RFC4458]. 


2. Problem Statement 
2.1. Interworking Requirements and Scope 


This section provides the baseline terminology used in the rest of 
the document and defines the scope of interworking between the 
Diversion header and the History-Info header. 


There are many ways in which SIP signaling can be used to modify a 
session destination before it is established, and there are many 
reasons for doing so. The behavior of the SIP entities that will 
have to further process the session downstream will sometimes vary 
depending on the reasons that lead to changing the destination. For 
example, whether it is for a simple proxy to route the session or for 
an application server to provide a supplementary service. The 
Diversion header and the History-Info header differ in the approach 
and scope of addressing this problem. 


For clarity, the following vocabulary is used in this document: 


o Retargeting/redirecting: retargeting/redirecting refers to the 
process of a Proxy Server/User Agent Client (UAC) changing a 
Uniform Resource Identifier (URI) in a request and thus changing 
the target of the request. These terms are defined in [RFC4244]. 
The History-Info header is used to capture retargeting 
information. 


o Call forwarding/call diversion/communication diversion: these 
terms are equivalent and refer to the Communications Diversion 
(CDIV) supplementary services, based on the Integrated Services 
Digital Network (ISDN) Communication diversion supplementary 


Mohali Informational [Page 4] 


RFC 6044 Mapping Diversion and History-Info October 2010 


services and defined in 3GPP [TS _ 24.604]. They are applicable to 
entities that are intended to modify the original destination of 
an IP multimedia session during or prior to the session 
establishment. 


This document does not intend to describe when or how History-Info or 
Diversion headers should be used. Hereafter is provided 
clarification on the context in which the interworking is required. 


The Diversion header has exactly the same scope as the call diversion 
service and each header entry reflects a call diversion invocation. 
The Diversion header is used for recording call forwarding 
information, which could be useful to network entities downstream. 
Today, this SIP header is implemented by several manufacturers and 
deployed in networks. 


The History-Info header is used to store all retargeting information 
including call diversion information. In practice, the History-Info 
header [RFC4244] is used to convey call-diversion-related information 
by using a cause URI parameter [RFC4458] in the relevant entry. 

Note, however, that the use of cause URI parameter [RFC4458] ina 
History-Info entry for a call diversion is specific to the 3GPP 
specification [TS_24.604]. [RFC4458] focuses on retargeting toward a 
voicemail server and does not specify whether the cause URI parameter 
should be added in a URI for other cases. As a consequence, 
implementations that do not use the cause URI parameter for call 
forwarding information are not considered for the mapping described 
in this document. Nevertheless, some recommendations are given in 
the next sections on how to avoid the loss of non-mapped information 
at the boundary between a network region using History-Info header 
and one using the Diversion header. 


Since both headers address call forwarding needs, diverting 
information could be mixed up or be inconsistent if both are present 
in an uncoordinated fashion in the INVITE request. So, Diversion and 
History-Info headers must not independently coexist in the same 
session signaling. This document addresses how to convert 
information between the Diversion header and the History-Info header, 
and when and how to preserve both headers to cover additional cases. 


For the transportation of consistent diversion information 
downstream, it is necessary to make the two headers interwork. 
Interworking between the Diversion header and the History-Info header 
is introduced in sections 5 and 6. Since the coexistence scenario 
may vary from one use case to another one, guidelines regarding 
headers interaction are proposed. 
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2.2. Interworking Recommendations 
Interworking function: 


In a normal case, the network topology assumption is that the 
interworking described in this document should be performed by a 
specific SIP border device that is aware, by configuration, that 
it is at the border between two regions, one using History-Info 
header and one using Diversion header. 


As History-Info header is a standard solution, a network using the 
Diversion header must be able to provide information to a network 
using the History-Info header. In this case, to avoid header 
coexistence, it is required to replace, as often as possible, the 
Diversion header with the History-Info header in the INVITE request 
during the interworking. 


Since, the History-Info header has a wider scope than the Diversion 
header, it may be used for other needs and services than call 


diversion. In addition to trace call diversion information, the 
History-Info header also acts as a session history and can store all 
successive R-URI values. Consequently, even if it should be better 


to remove the History-Info header after the creation of the Diversion 
header to avoid confusion, the History-Info header must remain 
unmodified in the SIP signaling if it contains supplementary (non- 
diversion) information. It is possible to have History-Info headers 
that do not have values that can be mapped into the Diversion header. 
In this case, no interworking with Diversion header should be 
performed, and it must be defined per implementation what to do in 
this case. This point is left out of the scope of this document. 


As a conclusion, it is recommended to have local policies minimizing 
the loss of information and find the best way to keep it up to the 
terminating user agent. 


The following sections describe the basic common use case. 
Additional interworking cases are described in section 7.5. 


2.2.1. SIP Network/Terminal Using Diversion to SIP Network/Terminal 
Using History-Info Header 


When the Diversion header is used to create a History-Info header, 
the Diversion header must be removed in the outgoing INVITE. It is 
considered that all of the information present in the Diversion 
header is transferred in the History-Info header. 
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If a History-Info header is present in the incoming INVITE (in 
addition to Diversion header), the Diversion header and History-Info 
header present must be mixed and only the diversion information not 
yet present in the History-Info header must be inserted as a last 
entry (more recent) in the existing History-Info header, as 
recommended in [RFC4244]. 


As an example, this could be the case of an INVITE coming from 
network_2 using the Diversion header but previously passed through 
network_1 using the History-Info header (or the network_2 uses 
History-Info header to transport successive URI information) and 
going to network_3 using the History-Info header. 


<sip:proxyP1>; index=1, 
<sip:userB>; index=1.1 
|<sip:userC>; cause=302; index=1.1.1 


IWE* IWE* 
network1 | network_2 |network_3 
History-Info Diversion using 
Hist-Info 
| | 
UA A P1 AS B | P2 AS C UA C ASD | UA E 
| | | | | | | | | 
| INVITE | | | | | | | | | 
ees eee a S 
| [Invite | | | | | | | 
| |------ > | | | | | | | | 
| | Supported: histinfo | | | | | | 
| | History-Info: | | | | | | 
<sip:proxyP1>; index=1, 
<sip:userB >; index=1.1 
| | | | | | | 
| [INVITE | | | | | | | 
| roue >| | | | | | | 
| | | | | | 
| | | | 


| 
| 
| 
| |History-Info: | 
| 


In this case, the incoming INVITE contains a Diversion header and a 
History-Info header. Therefore, as recommended in this document, it 
is necessary to create, for network_3, a single History-Info header 
gathering existing information from both the History-Info and the 
Diversion headers received. Anyway, it is required from network_2 
(i.e., IWF) to remove the Diversion header when the message is going 
to a network not using the Diversion header. Then, network_3 could 
use call forwarding information that is present in a single header 
and add its own diversion information if necessary. 
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2.2 


Notes: 


1. If a network is not able either to use only one header each time 
or to maintain both headers up to date, the chronological order 
cannot be certified. 


2. It is not possible to have only a Diversion header when the 
History-Info header contains more than call diversion information. 
If previous policy recommendations are applied, the chronological 
order is respected as Diversion entries are inserted at the end of 
the History-Info header taking into account the Diversion internal 
chronology. 


.2. SIP Network/Terminal Using History-Info Header to SIP 
Network/Terminal Using Diversion Header 


When the History-Info header is interpreted to create a Diversion 
header, some precautions must be taken. 


If the History-Info header contains only call forwarding information, 
then it must be deleted after the interworking. 


If the History-Info header contains other information, then only the 
information of concern to the diverting user must be used to create 
entries in the Diversion header and the History-Info header must be 


= 


kept as received in the INVITE and forwarded downstream. 


Note: The History-Info header could be used for other reasons than 
call diversion services, for example, by a service that needs to know 
if a specific Application Server (AS) had yet been invoked in the 
Signaling path. If the call is later forwarded to a network using 
the History-Info header, it would be better not to lose history 
information due to passing though the network that only supports 
Diversion headers. A recommended solution must not disrupt the 
standard behavior and networks that do not implement the History-Info 
header must be transparent to a received History-Info header. 


If a Diversion header is present in the incoming INVITE (in addition 
to History-Info header), only diversion information present in the 
History-Info header but not in the Diversion header must be inserted 
from the last entry (more recent) into the existing Diversion header, 
as recommended in [RFC5806]. 


Note that the chronological order could not be certified. If 
previous policy recommendations are respected, this case should not 
happen. 
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Forking case: 


The History-Info header enables the recording of sequential 
forking for the same served user. During an interworking, from 
the History-Info header to Diversion header, the History-Info 
entries containing a forking situation (with an incremented 
"index" parameter) could possibly be mapped if it contains a call 
forwarding "cause" parameter. The interworking entity could 
choose to create only a Diversion entry or not apply the 
interworking. The choice could be done according a local policy. 


The same logic is applied for an interworking with Voicemail URI (see 
the Appendix). 


3. Headers Syntaxes Reminder 


3.1. History-Info Header Syntax 


History-Info = "History-Info" HCOLON hi-entry * (COMMA hi-entry) 
hi-entry = hi-targeted-to-uri *( SEMI hi-param ) 
hi-targeted-to-uri = name-addr 
hi-param = hi-index / hi-extension 
hi-index = "index" EQUAL 1*DIGIT * (DOT 1*DIGIT) 
hi-extension = generic-param 

The History-Info header is specified in [RFC4244]. The top-most 


History-Info entry (first in the list) corresponds to the oldest 
history information. 


A hi-entry may contain a cause URI parameter expressing the diversion 
reason. This optional cause URI parameter is defined in [RFC4458] 
with the following syntax: 


cause-param = "cause" EQUAL Status-Code 


This parameter is also named cause-param and should be inserted in 
the History-Info entry (URI) of the diverted-to user in case of call 
diversion as recommended in the 3GPP CDIV specification [TS_24.604]. 
The cause values used in the cause-param for the diverting reason are 
listed in the RFC 4458, and because it is a parameter dedicated to 
call forwarding service, its presence is used to determine that a hi- 
entry is a diverting user. More precisely, each diverting user is 
located in the hi-entry before the one containing a cause-param with 
a cause value as listed in RFC 4458. 
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Moreover, the Reason header defined in [RFC3326] should be escaped in 
the hi-entry of the diverting user when the call diversion is due to 
a received SIP response. The Reason header contains a cause 
parameter set to the true SIP response code received (Status-Code). 
Therefore, in case of call diversion due to a SIP response, both 
cause parameters should be used. The complexity is that these 
parameters could be used at the same time in the History-Info header 
but not in the same hi-entry and not with the same meaning. Only the 
cause-param is dedicated to call diversion service. The ’cause’ 
Reason header parameter is not taken into account in the mapping with 
a Diversion header. 


[RFC4458] also defines the ’target’ URI parameter, which could be 
inserted in a R-URI and consequently in the hi-targeted-to-uri. This 
parameter is used to keep the diverting user address in the 
downstream INVITE request in Voicemail URI implementation. As this 
information is already present in the hi-entries, the ’/target’ URI 
parameter is not taken into account regarding the interworking with 
the Diversion header. From the Diversion header, it could be 
possible to create the ’target’ URI parameter in the hi-entries 
and/or in the R-URI, but this possibility is based on local policies 
not described in this document. 


A Privacy header, as defined in [RFC3323], could also be included in 
hi-entries with the ’history’ value defined in the [RFC4244]. 


The index parameter is a string of digits, separated by dots, to 
indicate the number of forward hops and retargets. 


Note: A history entry could contain the "gr" parameter. Regardless 
of the rules concerning the "gr" parameter defined in [TS_24.604], 

which must be applied, this parameter has no impact on the mapping 

and must only be copied with the served user address. 


Example: 


History-Info: 

<sip: diverting_userl_addr?Privacy=none?Reason=SIP%3Bcause% 
3D302>;index=1, 

<sip: diverting_user2_addr; cause=480?Privacy=history>; index=1.1, 
<sip:last diversion target;cause-486>; index=1.1.1 


Policy concerning "histinfo" option tag in Supported header: 
According to [RFC4244], a proxy that receives a Request with the 
"histinfo" option tag in the Supported header should return captured 
History-Info in subsequent, provisional and final responses to the 
Request. The behavior depends upon whether or not the local policy 
supports the capture of History-Info. 


Mohali Informational [Page 10] 


RFC 6044 Mapping Diversion and History-Info October 2010 


3.2. Diversion Header Syntax 


The following text is restating the exact syntax that the production 
rules in [RFC5806] define, but using [RFC5234] ABNF: 


Diversion = "Diversion" HCOLON diversion-params 
* (COMMA diversion-params) 


name-addr *(SEMI (diversion-reason / 
diversion-counter / diversion-limit / 
diversion-privacy / diversion-screen / 
diversion-extension) ) 

diversion-reason = "reason" EQUAL ("unknown" / "user-busy" / 
"no-answer" / "unavailable" / "unconditional" 
/ “time-of-day" / "do-not-disturb" / 
"deflection" / "follow-me" / "out-of-service" 
/ “away" / token / quoted-string) 


diversion-params 


diversion-counter = "counter" EQUAL 1*2DIGIT 

diversion-limit = "limit" EQUAL 1*2DIGIT 

diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" / 
"off" / token / quoted-string) 

diversion-screen = "screen" EQUAL ("yes" / "no" / token / 


quoted-string) 
token [EQUAL (token / quoted-string) ] 


diversion-extension 
Note: The Diversion header could be used in the comma-separated 
format, as described below, and in a header-separated format. Both 
formats could be combined a received INVITE as recommended in 
[RFC3261]. 

Example: 


Diversion: 


diverting_user2_addr; reason="user-busy"; counter=1; privacy=full, 
diverting_userl_addr; reason="unconditional"; counter=1; privacy=off 


4. Headers in SIP Method 


The recommended interworking presented in this document should apply 
only for INVITE requests. 


In 3xx responses, both headers could be present. 
When a proxy wants to interwork with a network supporting the other 


header field, it should apply the interworking between Diversion 
header and History-Info header in the 3xx response. 
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When a recursing proxy redirects an initial INVITE after receiving a 
3xx response, it should add as a last entry either a Diversion header 
or a History-Info header (according to its capabilities) in the 
forwarded INVITE. Local policies could apply to send the received 
header in the next INVITE. 


Other messages where History-Info could be present are not used for 
the call forwarding service and should not be changed into Diversion 
header. The destination network must be transparent to the received 
History-Info header. 


Note: the following mapping is inspired from the ISDN User Part 
(ISUP) to the SIP interworking described in [TS_29.163]. 


5. Diversion Header to History-Info Header 


The following text is valid only if no History-Info is present in the 
INVITE request. If at least one History-Info header is present, the 
interworking function must adapt its behavior to respect the 
chronological order. See section 2.2. 


For N Diversion entries, N+1 History-Info entries must be created. 

To create the History-Info entries in the same order than during a 
session establishment, the Diversion entries must be mapped from the 
bottom-most until the top-most. Each Diversion entry shall be mapped 
into a History-Info entry. An additional History-Info entry (the 
last one) must be created with the diverted-to party address present 
in the R-URI of the received INVITE. The mapping is described below. 


The first entry created in the History-Info header contains: 


— a hi-targeted-to-uri with the name-addr parameter of the bottom- 
most Diversion header. 


— if a privacy parameter is present in the bottom-most Diversion 
entry, then a Privacy header could be escaped in the History-Info 
header as described below. 


— an index set to 1. 


For each following Diversion entry (from bottom to top), the History- 
info entries are created as following (from top to bottom): 
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Mapping Diversion and History-Info 
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estination 


History-Info header component: 


name-addr h 


i-targeted-to-uri 


Reason of the previous cause-param (not present in 
Diversion entry the first created hi-entry) 
MUN KNOWN ESS SES ESS SoS SSeS See 404 (default ’cause’ value) 
"unconditional"--------------------------- 302 

MUST DUSV === SES ss 486 

"no-answer" —--------- 5-5 5 408 

"deflections Mes See 480 or 487 

"unavailable"----- an 404 

Mtime-oft-dav'=- ss ss 404 (default) 
MAG-not-disSturbl=-- esse sss ses ses 404 (default) 

MÉOLIOWEME TEE SE SES ESS TRES SES 404 (default) 
NOULHOL=SerViCe"SaSSss555$eSSsseSsSs=5555 404 (default) 

NAWAY Senn SaaS Sasa sa SES See 404 (default) 

Counter hi-index 

"LT" OT: parameter: SSSR ES See The previous created index 


not present 
Superior to "1" 


is incremented with ".1" 
Create N-1 placeholder History 


(i.e., N) entry with the previous index 
incremented with ".1" 
Then the History-Info header 
created with the Diversion 
entry with the previous index 
incremented with ".1" 

Privacy Privacy header escaped in the 
hi-targeted-to-uri 

MÉURITMES SSSR SSSR TS SSSR ESS See "history" 

OCR ee Privacy header field 
absent or "none" 

POMC ME SRE SaaS se "history" 

MUG SSS SS SS a a SSeS SS Se ae eee "history" 


A last History-Info entry is created an 
— a hi-targeted-to-uri with the Request 


— à cause-param from the top-most Diver 
diversion-reason as described above. 


Mohali Informationa 
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— if a privacy parameter is present in the top-most Diversion entry, 
then a Privacy header could be escaped in the History-Info header 
as described above. 


— an index set to the previous created index and incremented with 
Lied DR 


Notes: 


1. For other optional Diversion parameters, there is no 
recommendation as History-Info header does not provide equivalent 
parameters. 


2. For values of the diversion-reason values that are mapped with a 
recommended default value, it could also be possible to choose 
another value. The cause-param URI parameter offers less possible 
values than the diversion-reason parameter. However, it has been 
considered that cause-param values list was sufficient to 
implement CDIV service as defined in 3GPP [TS_24.604] as it covers 
a large portion of cases. 


3. The Diversion header could contain a Tel:URI in the name-addr 
parameter, but it seems not possible to have a Tel:URI in the 
History-Info header. [RFC3261] gives an indication as to the 
mapping between sip: and Tel:URIs, but in this particular case, it 
is difficult to assign a valid hostport as the diversion has 
occurred in a previous network and a valid hostport is difficult 
to determine. So, it is suggested that in case of Tel:URI in the 
Diversion header, the History-Info header should be created with a 
SIP URI with user=phone. 


4. The Diversion header allows the carrying of a counter that retains 
the information about the number of successive redirections. The 
History-Info header does not have an equivalent because to trace 
and count the number of diversion it is necessary to count cause 
parameter containing a value associated to a call diversion. Read 
the index value is not enough. With the use of the "placeholder" 
entry, the History-Info header entries could reflect the real 
number of diversion occurred. 


Example of placeholder entry in the History-Info header: 
<sip:unknown@unknown. invalid; cause=xxx>; index=1.1 


<sip:bob_addr; cause=404>; index=1.1.1 
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"cause=xxx" reflects the diverting reason of a previous diverting 
user. For a placeholder hi-entry, the value "404" must be taken for 
the cause-param and so, located in the next hi-entry. 


Concerning local policies recommendations about headers coexistence 
in the INVITE request, see sections 2.2 and 7.5. 


6. History-Info Header to Diversion Header 


To create the Diversion entries in the same order than during a 
session establishment, the History-Info entries must be mapped from 
the top-most until the bottom-most. The first History-Info header 
entry selected will be mapped into the last Diversion header entry 
and so on. One Diversion header entry must be created for each 
History-Info entry, with a cause-param reflecting a diverting reason 
as listed in the [RFC4458]. 


In this case, the History-Info header must be mapped into the 
Diversion header as following: 
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Source Destination 
History-Info header component: Diversion header component: 
hi-targeted-to-uri of the name-addr 


History-Info that precedes the one 
containing a diverting cause-param. 


cause-param Reason 

ARO C — "unknown" (default value) 
SO DSS aS a eS eae a See aS "unconditional" 

ABC RSR aa ma "user-busy" 
ROBES ee "no-answer" 

480 or 487--——————————————— E "deflection " 

SO SR SSS a eee re See "unavailable" 

hi-index Counter 

Mandatory parameter for-------------------- The counter is set to "1". 


History-Info reflecting 
the chronological order 
of the information. 


Privacy header [RFC3323] escaped in the Privacy 
hi-targeted-to-uri of the 

History-Info, which precedes the one 

containing a diverting cause-param. 

Optional parameter for History-Info, 

this Privacy indicates that this 

specific History-Info header should 

not be forwarded. 

MALSCOLY (SSeS cS SSSR SSS SSR RSS SSS sss full” 
Privacy header field ---------------------- MOT 
Absent or "none" 


Note: For other optional History-Info parameters, there is no 
recommendation as Diversion header does not provide equivalent 
parameters. 


Concerning local policies recommendations about headers coexistence 
in the INVITE request, see section 2.2. 
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7. 


7. 


7 


7. 


Ia 


aoe 


3. 


Examples 
Example with Diversion Header Changed into History-Info Header 


INVITE last_diverting_target 

Diversion: 
diverting_user3_address;reason=unconditional;counter=1;privacy=off, 
diverting_user2_address;reason=user-busy;counter=1;privacy=full, 
diverting_userl_address; reason=no-answer; counter=1; privacy=off 


Mapped into: 


History-Info: 

<sip: diverting_ userl_ address; privacy=none >; index=1, 

<sip: diverting_user2 address; cause=408?privacy=history>; index=1.1, 
<sip: diverting_user3_address; cause=486?privacy=none>; index=1.1.1, 
<sip: last_diverting_target; cause=302>;index=1.1.1.1 


Example with History-Info Header Changed into Diversion Header 


History-Info: 

<sip: diverting_userl_address?privacy=history >; index=1, 

<sip: diverting_ user2_ address; cause=302? privacy=none>; index=1.1, 
<sip: last _diverting target; cause=486>;index=1.1.1 


Mapped into: 


Diversion: 

diverting_user2 address; reason=user-busy; counter=1; privacy=off, 
diverting_userl_address; reason=unconditional; counter=1; 
privacy=full 


Example with Two SIP Networks Using History-Info Header 
Interworking with a SIP Network Using Diversion Header 


A -> Pl -> B -> C -> P2 -> D-> E 

A, B, C, D and E are users. 

B, C and D have Call Forwarding service invoked. 

P1 and P2 are proxies. 

Only relevant information is shown on the following call flow. 
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IWE * IWF* 


SIP network using 
Diversion 


| 

| 
P1 AS B | 2 AS C UA C S D 

| 

| 


| Supported: histinfo 
| History-Info: 

| <sip:proxyP1>; index=1, 
<sip:userB >; index=1.1 


[INV c | 


P 
| 
| 
| 
1 


|History-Info: | 

<sip:proxyP1>; index=1, 
<sip:userB>; index=1.1 
<sip:userC; cause=302>; index=1.1.1 


S A 
| | 
| | 
| | 
| | 
| | 
| | 


A 
| 
| 
| 
| 
| 


| 
[INV c | 
| | 


|Diversion: | | | 

B reason= unconditional counter=1 
History-Info: | | 
<sip:proxyP1>; index=1, | | 
<sip:userB>; index=1.1 | | 
<sip:proxyP2; cause=302>; index=1.1. 


----—- > 
<--180- 


| 
| 
| 
| | INV C | 
| 
| 
| 


| 
| No response timer expire 
| |---INV D --->| 


Informational 


No modification of Diversion due to P2 


|SIP net. 
|using 
Hist-Info 


UA 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
1 
| 


E 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

| | 
| | 
| | 
| | 
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|Diversion: | | | 

|userC; reason=no-answer; counter=1; privacy=full, | 

userB; reason=unconditional; counter=1; privacy=off, 
History-Info: 

| <sip:proxyP1>; index=1, | | 

| <sip:userB>; index=1.1 | | 

| <sip:proxyP2; cause=302>; index=1.1.1 | 


| | | ee E 


| 
| 
| 
| 
|Diversion: | | 
|userD; reason=time-of-day; counter=1; privacy=off | 
|userC; reason=no-answer; counter=1; privacy=full, | 
luserB; reason=unconditional; counter=1; privacy=off, 
| History-Info: | | 
<sip:proxyP1>; index=1, 
| <sip:userB>; index=1.1 | | 
| <sip:proxyP2; cause=302>; index=1.1.1 | | 
| | | | | | | | 
| | | | | | | | 
| | | | | | ee >| 
History-Info: 
| <sip:proxyP1>; index=1, | 
| <sip:userB ?privacy=none>; index=1.1, | 
| <sip:proxyP2; cause=302>; index=1.1.1, | 
| <sip:userC ?privacy=history>; index=1.1.1.1, | 
<sip:userD; cause=408 ?privacy=none>; index=1.1.1.1.1, 
<sip:userE; cause=404>; index=1.1.1.1.1.1 


* Note: The IWF is an interworking function that could be a stand- 
alone equipment not defined in this document (it could be a proxy). 


7.4. Additional Interworking Cases 


Even if for particular cases in which both headers could coexist, it 
should be the network local policy responsibility to make it work 
together. Here are described some situations and some 
recommendations on the behavior to follow. 


In the case where there is one network that includes different nodes, 
some of them supporting the Diversion header and other ones 
supporting the History-Info header, there is a problem when any node 
handling a message does not know the next node that will handle the 
message. This case can occur when the network has new and old nodes, 
the older ones using Diversion header and the more recent History- 
Info header. 
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While a network replacement may be occurring, there will be a time 
when both nodes coexist in the network. If the different nodes are 
being used to support different subscriber types due to different 
node capabilities then the problem is more important. In this case, 
there is a need to pass both History-Info header and Diversion header 
within the core network. 


These headers need to be equivalent to ensure that, whatever the node 
receiving the message, the correct diversion information is received. 
This requires that whatever the received header, there is a 
requirement to be able to compare the headers and to convert the 
headers. Depending upon the node capability, it may be possible to 
make assumptions as to how this is handled. 


o If it is known that the older Diversion header supporting nodes do 
not pass on any received History-Info header, then the 
interworking becomes easier. If a message is received with only 
Diversion headers, then it has originated from an ’old’ node. The 
equivalent History-Info entries can be created and these can then 
be passed as well as the Diversion header. 


o If the node creates a new History-Info header for a call 
diversion, then an additional Diversion header must be created. 


o If the next node is an ’old’ node, then the Diversion header will 
be used by that node and the History-Info entries will be removed 
from the message when it is passed on. 


o If the next node is a new node then the presence of both Diversion 
header and History-Info header means that interworking has already 
occurred and the Diversion and History-Info entries must be 
considered equivalent. 


o If both nodes pass on both History-Info header and Diversion 
header, but only actively use one, then both types of nodes need 
to perform the interworking and must maintain equivalence between 
the headers. This will eventually result in the use of Diversion 
header being deprecated when all nodes in the network support 
History-Info header. 


8. Security Considerations 
The security considerations in [RFC4244] and [RFC5806] apply. 
The use of the Diversion header or the History-Info header require 
the application of the requested privacy and integrity asked by each 


diverting user or entity. Without integrity, the requested privacy 
functions could be downgraded or eliminated, potentially exposing 
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identity information. Without confidentiality, eavesdroppers on the 
network (or any intermediaries between the user and the privacy 
service) could see the very personal information that the user has 
asked the privacy service to obscure. Unauthorized insertion, 
deletion of modification of those headers, can provide misleading 
information to users and applications. A SIP entity that can provide 
a redirection reason in a History-Info header or a Diversion header 
should be able to suppress this in accordance with privacy 
requirements of the user concerned. 
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Appendix A. Interworking between Diversion Header and Voicemail URI 


Voicemail URI is a mechanism described in RFC 4458 to provide a 
simple way to transport only one redirecting user address and the 
reason why the diversion occurred in the R-URI of the INVITE request. 
This mechanism is mainly used for call diversion to a voicemail. 


Diversion header to Voicemail URI: 


Received: 
Diversion: userA-address; reason=user-—busy; counter=1; privacy=full 


Sent (Voicemail URI created in the R-URI line of the INVITE): 
sip: voicemail@example.com;target=userA-address; cause=486 SIP/2.0 


Mapping of the Redirection Reason is the same as for History-Info 
header with a default value set to 404. 


If the Diversion header contains more than one Diversion entry, the 
choice of the redirecting user information inserted in the URI is in 
charge of the network local policy. For example, the choice 
criterion of the redirecting information inserted in the URI could be 
the destination of forwarded INVITE request (whether or not the 
voicemail serves this user). 


Note: This interworking could be done in addition to the interworking 
of the Diversion header into the History-Info header. 


Voicemail URI to Diversion header: 


In case of real voicemail, this way of interworking should not 
happen. However, if for any reason it occurs, it is recommended to 
do it as following: 


Received: 

INVITE sip: voicemail@example.com; \ 
target=sip:+33145454500%40example.com; user=phone; \ 
cause=302 SIP/2.0 


Sent in the forwarded INVITE: 
Diversion: sip:+ 
33145454500%40example.com; user=phone; reason=unconditional; counter=1 
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